개요

많은 실무 환경에서 컨테이너 환경으로 전환하는 움직임을 보이지만, 아직까지도 실제 워크로드를 자주 가상머신이나 물리 머신에 띄우는 곳은 수두룩하다.
엔터프라이즈 환경에서는 규제 준수 때문에 어쩔 수 없이 온프레미스 환경에서 실행해야 할 수 있다.
그리고 컨테이너화라는 것도 규모가 큰 환경에서는 의존성 등의 이슈로 간단한 작업이 아니다.

그래서 이스티오의 기본은 쿠버네티스 클러스터에서 활용하는 것이지만, 서비스 메시로서 쿠버 환경 너머의 환경도 통합할 수 있도록 지원하고 있다.^[1]
그래서 이번에는 이스티오라는 서비스 메시를 가상머신 환경과 통합하는 환경을 보고자 한다.

굳이 어렵게 통합을 해서 얻는 이점이라 한다면 역시 서비스 메시 환경으로의 통합적 관리가 가능하다는 점일 것이다.
서비스 디스커버리, 트래픽 관리, 보안 등 서비스 메시로서 성취할 수 있는 장점들을 레거시 환경에서 누릴 수도 있다는 것은 당연한 장점이 된다.
여기에 이스티오 도입을 고려하거나 마이그레이션을 진행하는 조직에 있어서는 점진적인 마이그레이션을 고려할 수 있게 해준다는 점에서 굉장히 유의미한 선택지가 될것이다.

가상머신 통합 전략

본격적으로 방법을 알아보기 전에 어떤 식으로 서비스 메시 환경과 가상 머신을 결합할 수 있는지 전략들을 간단하게 훑어본다.^[2]

(아래에서 조금 더 자세히 말하겠지만 결국 서비스 메시는 컨트롤 플레인이 데이터 플레인의 프록시를 관리하는 형태를 가지고 있으니, 가상 머신에 프록시를 세팅하는 것이 곧 메시를 통합하는 작업이다.)
가장 기본적인 전략은 말 그대로 가상 머신을 서비스 메시에 온보딩시키는 것이다.
이때 네트워크의 연결을 위해 게이트웨이를 배치하고 이를 통해 데이터 플레인 간 통신을 달성시킬 수 있다.

조금 더 복잡하게 네트워크 구성도를 가져가야 하는 조직도 있을 수 있다.
인바운드와 아웃바운드의 제한이 엄격한 조직에서는 가상 머신 환경으로의 인입을 위해서 로드 밸런서를 앞단에 배치해야 할 수 있다.
이런 경우 로드 밸런서가 적절하게 트래픽을 라우팅할 수 있도록 각종 이스티오의 게이트웨이가 그러하듯이 가상 호스트로서 기능할 수 있어야 할 것이다.

아웃바운드 트래픽도 엄격하게 제한하는 환경이라면 포워드 프록시를 배치하는 방식으로 운용해야 한다.
이게 필수적인 환경도 있겠지만, 각 가상머신마다 프록시를 배치하는 것이 부담되는 조직에서도 충분히 고려할 만한 전략이 될 수 있겠다.

위의 로드밸런서 배치와 포워드 프록시를 짬뽕시켜서 아웃바운드와 인바운드 트래픽의 경로가 완전히 다른 방식의 구성도를 가져가야 하는 경우도 생각해볼 수 있다..
이런 모든 케이스들에 대해서 이스티오에서 편의적인 세팅을 지원하는 건 아니다.
아무튼 각 조직의 여건에 맞게 이러한 전략들을 선택할 수 있다는 것이다.

가상머신 통합 과제

서비스 메시로서 통합한다는 것은 결국 컨트롤 플레인으로부터 데이터 플레인이 관리를 받는 구조를 만드는 것이라고 요약할 수 있다.
그렇다면 이러한 구조를 만들 때 당면하게 되는 과제와 고려사항은 무엇이 있을까.
구체적으로 충족돼야 하는 것들은 다음의 것들이 있다.

• 프록시 설정
  • 데이터 플레인으로서 네트워크 기능을 전담하는 사이드카 프록시가 가상 머신에 설치돼야 한다.
  • 이는 가상 머신에 엔보이를 구축하는 것으로 귀결된다.
• 네트워크 연결성
  • 가상 머신과 클러스터 환경이 서로 통신할 수 있는 구조가 구축돼야 한다.
  • 각종 설정을 받고 상태 정보를 전달할 수 있도록 컨트롤 플레인 istiod와 통신할 수 있어야 한다.
  • 무엇보다 다른 데이터 플레인의 서비스와 통신이 가능해야 메시라고 할 수 있을 것이다!
  • 다른 네트워크라면 보통 클러스터에 동서 게이트웨이를 두는 식으로 충족된다.
• 서비스 디스커버리
  • 가상 머신과 클러스터는 서로의 서비스를 탐색할 수 있어야 하고, 디스커버리를 기반으로 통신이 가능해야 한다.
  • 같은 컨트롤 플레인의 제어를 받는다면 기본적으로는 해결된다고 볼 수 있으나, 조금 고려할 사항이 더 있다.
  • 가상 머신 to 클러스터 서비스
    • 클러스터에서 사용되는 호스트 정보를 통해 통신할 수 있어야 한다.
    • 별도의 DNS 프록시 세팅이 필요하다.
  • 클러스터 서비스 to 가상 머신
    • 컨트롤 플레인이 가상 머신을 서비스로 인식하고 관리할 수 있도록 하는 리소스가 필요하다.
• 신원 설정
  • 가상 머신이 클러스터에서 활용되는 신뢰 도메인에 기반해 워크로드 신원을 가져야 한다.
  • 그래야 가상 머신의 트래픽이 온전히 메시 내부의 트래픽으로서 인식될 수 있을 것이다.
  • 루트 CA를 기반으로 가상 머신에 인증서를 세팅하는 것으로 충족된다.

이것들은 일반 클러스터에 있었으면 전부 자동으로 되던 일들이다.
프록시, 신원은 워크로드가 배치될 때 사이드카가 주입되면서 해소되고, 네트워크에 대해서는 같은 클러스터에 있기에 자동으로 충족된다.
가상 머신의 경우 이를 전부 직접 설정을 해서 충족시켜야 한다.
해야 하는 일만 요약하자면 프록시 세팅, 게이트웨이 구축, 토큰이나 인증서 등의 신원 설정을 해야 한다는 것이다.

몇 가지 직접 해야 하는 일들이 있긴 하나 이스티오에서는 이것들을 최대한 단순하게 할 수 있는 방법을 제공하긴 한다.

이스티오의 방법

이 그림은 가상 머신을 통합하기 위해서 해야 하는 전반적인 작업을 보여준다.^[3]
먼저 가상머신이 istiod에 접근할 수 있도록 세팅한다.
그리고 가상머신이 클러스터에서 사용할 신원을 서비스 어카운트로 세팅하고, 가상머신을 서비스로 인지하고 관리할 수 있도록 하는 리소스를 만든다.
이후에는 가상 머신에 각종 설정 파일을 넣어서 프록시를 구축한다.
여기에 들어가는 설정 파일은 실습하면서 살펴보자.

이게 기본 방식으로 이스티오에서 최대한 간편하게 세팅할 수 있도록 지원해주고 있다.
이스티오의 가상머신 지원 기능은 1.9.0에서 핵심 기능 일부가 구현되고 1.25 기준 현재에 이르러서는 코어 기능으로 합류됐다.
이때의 핵심 기능이란,

• 가상머신에서의 사이드카 프록시 설치 및 설정 - istioctl 명령어 제공
• 가상머신 관리와 고가용성 - Istio WorkloadGroup, Istio WorkloadEntry 커스텀 리소스
  • 사실 잘 와닿지는 않지만, 이스티오는 가상머신의 가용성까지 고려하는 것을 강제시킨다.
• 가상머신에서 메시 내 서비스 DNS 해석 - 사이드카와 함께 설정되는 로컬 DNS 프록시

각각의 기능과 원리를 조금 더 자세히 파보자.

사이드카 프록시 설치 및 설정

잠시 클러스터에서 워크로드가 배치될 때 일어나는 과정을 잠시 생각해보자.
워크로드가 배치되면 먼저 Mutating Admission Webhook을 통해 파드의 양식이 수정된다.
이때 일어나는 과정은 다음과 같다.

• iptables를 조작해 인바운드, 아웃바운드 트래픽이 전부 엔보이를 거치도록 세팅한다.
• pilot-agent가 초기 세팅을 진행한다.
  • kube-apiserver로부터 주입된 서비스 어카운트 토큰과 루트 인증서를 기반으로 CSR을 만든다.
  • 이를 CA 서버(기본 세팅에서는 istiod)에 날려서 인증서를 받아 스피페를 준수하는 워크로드 신원을 세팅한다.
    • 엔보이가 통신 시 사용할 수 있도록 자체 SDS 소켓을 리스닝한다.
  • istiod와 통신하며 엔보이 설정을 받을 통로를 열어둔다.
• pilot-agent가 엔보이를 실행시킨다.
  • 엔보이는 pilot-agent로부터 SDS 포함 모든 XDS 설정을 받아 설정된다.

이 과정을 통해 프록시는 데이터 플레인의 일원으로서 기능할 수 있게 된다.
고유한 신원을 가지고 컨트롤 플레인과 통신하며 설정을 동기화하고, 워크로드의 모든 트래픽을 처리해낸다.
가상머신에서도 이러한 작업이 똑같이 일어나면 가상머신 역시 데이터 플레인으로서 기능할 수 있을 것이다!
iptables, pilot-agent 배치 등의 동작은 사실 그냥 해당 가상머신에 관련한 패키지만 세팅해서 비교적 쉽게 자동화시킬 수 있다.

다만 여기에서 문제는 바로 서비스 어카운트 토큰과 루트 인증서.
이스티오는 기본적으로 쿠버네티스를 이용해 워크로드의 신원을 제공한다.
달리 말해 클러스터 외부의 가상머신 역시 쿠버네티스의 신원을 활용해야 한다는 말이다..
그렇기 때문에, 세팅할 때 쿠버네티스 서비스 어카운트 토큰과 인증서를 받아와 가상머신에 주입하는 추가적인 파이프라인이 필요하다.
이 작업을 위한 설정 파일들을 istioctl로 만들어낼 수 있긴 한데, 그럼에도 가상머신에 해당 파일들을 넣는 데에는 조금의 수작업이 필요하다.
실제로 운영할 때는 이 부분을 재량껏 손봐서 자동화시키는 스크립트를 잘 만들어내는 것이 중요한 운영 업무가 될 것이다.

가상머신 관리

클러스터 외부의 가상 머신이 메시에 편입되는 것은 위의 과정을 통해 완료될 것이다.
그러나 운영자가 메시 트래픽을 관리하는데 있어 라우팅 경로를 설정하거나, 백엔드의 헬스 상태를 체크하고자 할 때 여전히 가상머신은 클러스터 입장에서는 미지의 존재로 남아있다.
그래서 이들을 이스티오 네이티브하게, 조금 더 투명하게 관리할 수 있도록 만들어주는 커스텀 리소스가 바로 이스티오 워크로드엔트리, 이스티오 워크로드그룹이다.
간단하게 말해서 워크로드 엔트리는 각 가상 머신을 매핑하는 리소스이다.
워크로드 그룹은 엔트리를 자동 생성하고 헬스체크를 할 수 있게 도와주는 그룹 단위 리소스이다.

워크로드 리소스 배경

이들이 왜 필요한지 먼저 간단하게 짚어보자.

이스티오에서 클러스터 외부의 엔드포인트를 서비스로서 관리할 때는 이스티오 서비스엔트리를 활용한다.^[5]
특정 호스트를 서비스로 인식하여 관리하는 것만으로 치자면 이걸로 충분하다.

그러나 클러스터의 파드와 비교하자면, 이런 간단한 수준의 엔드포인트 관리는 너무 아쉬운 것이다.
파드는 라벨, 상태, 신원 정보를 가지고 있어 이를 기반으로 상세한 관리가 가능하다.
실제 이스티오를 운영하는 관리자는 해당 워크로드를 향한 설정을 이스티오 네이티브하게 관리할 수 있는 것이 좋을 것이다.
구체적으로 다음의 작업들을 하고 싶을 수 있다.

• 트래픽 라우팅 및 로드밸런싱
• 헬스 체크 기반 엔드포인트 관리

그래서 가상 머신에 대해서도 파드와 같은 수준의 정보를 세팅하고 관리할 수 있도록 고안된 것이 이 워크로드 엔트리이다.
이를 위해 워크로드 엔트리는 외부의 워크로드와 1:1로 매핑되도록 설계됐다.

워크로드 그룹의 기능 - 엔트리 자동 등록, 헬스체크

워크로드 엔트리는 가상머신을 나타내는 리소스라는 설명으로 일단 충분하고, 워크로드 그룹은 뭐하는 놈이냐?

워크로드 그룹 리소스의 핵심은 워크로드 엔트리 자동 등록이다.

처음 가상 머신이 메시에 등록될 때, istiod는 관련 정보를 검증하고 문제가 없다면 들어온 정보를 기반으로 알아서 워크로드 엔트리를 만든다.

여기에 추가적으로 워크로드 그룹을 통해 가상 머신의 헬스 상태를 보고하도록 설정할 수 있다.
이스티오에서의 헬스 체크는 트래픽을 보내는 클라 측의 이상치 탐지도 있긴 하다.
하지만 클라의 헬스 체크는 언젠가 복구될 것을 전제하며 잠시 해당 엔드포인트를 제외시키는 방식으로만 동작한다.
그런데 정말 문제가 생긴 케이스라면 아예 서비스 레지스트리에서 엔드포인트가 제거되는 것이 바람직하다.
클러스터 내의 파드야 이게 api 서버와 통신해서 편하게 확인되지만 가상머신은 그렇지 않기 때문에 여기에 헬스체크 설정을 넣을 수 있는 것이다.

설정을 넣으면 실제 헬스체크는 가상 머신에 배치된 프록시가 수행한다.
그리고 해당 정보를 istiod에게 주기적으로 보고하며, istiod는 이 정보를 워크로드 엔트리 리소스에 업데이트한다.

메시 내 서비스 DNS 해석

클러스터 내의 서비스 간에는 오버레이 네트워크를 통해 신나게 통신을 수행할 것이다.
이것은 Core DNS가 있고, 여차하면 엔보이에 직접 전달된 호스트에 대한 IP 정보가 있기 때문에 가능한 것이다.
그러나 당연히 가상 머신은 클러스터 내부의 주소를 기본적으로 알 방법이 없다.
하지만 서비스 메시로서 같은 서비스 레지스트리의 정보를 바탕으로 한 통신은 당연한 기본 요소이다.

이스티오 1.8 버전 이전에는 External DNS를 활용하는 등의 차선책을 썼으나, 이후에는 아예 pilot-agent가 DNS 서버로서 역할을 할 수 있는 기능이 추가됐다.
이 기능을 DNS 프록시라고 부른다.^[6]

이 부분에 대해서는 이후에 조금 더 자세히 다룬다.

실습 진행

기본적인 모든 세팅은 테라폼을 이용했다.

자세한 파일 정보는 이 레포를 참고하기 바란다.
무조건 원 클릭 딸깍으로 배포가 가능하게 하는 것을 목표로 삼았다.
각 환경에는 ssh를 통해 로컬에서 접근 가능하며, k3s 설치 시 클러스터 인스턴스의 공인 ip도 SAN으로 인증서에 등록하게 만들어 내 로컬에서 kubectl 통신이 가능하게 만들었다.

단 두 개의 인스턴스!

단 하나의 vpc!
나중에 알았지만, 사실 가상 머신 통합하는 것 자체보다 네트워크 관련 이슈 대처하는 게 더 큰 문제라 그냥 이렇게 했을 때 단순하게 할 수 있었던 듯..
암튼.

apt install termshark -y 

다른 건 전부 유저데이터로 넣었으나, 패킷을 뜯어보는데 사용할 termshark라는 놈은 직접 세팅해야 한다.
패킷을 뜯는 권한을 가진 툴이라 무조건 대화형으로 설치를 수행해야 하기 때문이다.
어차피 상태 체크, 파일 분석을 위해 인스턴스에 접근할 일이 많아 일찌감치 터미널 몇 개는 연결해두고 있는 편이 속 편하다.

기본 세팅

모든 세팅 스크립트를 순서대로 작성해두었다.

셩걱이 조금 달라진다 싶은 것들은 10의 자리수를 바꿔서 넣었는데, 좋은 방식인지는 모르겠다.
해당 스크립트를 적용할 때는 현 쉘 세션에 환경변수나 alias가 전부 적용될 수 있도록 무조건 source 명령어를 사용해야 한다.

해당 스크립트에 담긴 내용들을 조금 풀어서 세팅 설명을 진행한다.

apiVersion: install.istio.io/v1alpha1
metadata:
  name: istio-controlplane
  namespace: istio-system
kind: IstioOperator
spec:
  profile: demo
  components:
    egressGateways:
    - name: istio-egressgateway
      enabled: false
  values:
    global:
      meshID: usmesh
      multiCluster:
        clusterName: west-cluster
      network: west-network

간단하게 이스티오를 설치한다.
다른 네트워크를 가정하기 때문에 네트워크 정보를 명시한 것을 확인할 수 있다.

클러스터 인스턴스에 들어가서 이 명령어가 실행되면 성공이다!

같은 방식으로 vm 인스턴스에서도 문제가 없는지 체크해본다.

curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/catalog/items/1 | jq
while true; do curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/catalog/ ; echo; date; sleep 1; done

다른 네트워크를 가정했으므로 공인 IP를 이용해 통신을 진행해본다.

이 방식은 자신의 로컬에서 시도할 때도 성공해야 한다.

VM 통합하기

1. 이스티오 세팅

먼저 이스티오에서 가상머신을 받을 수 있도록 준비해보자.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-controlplane
  namespace: istio-system
spec:
  profile: demo
  components:
    egressGateways:
    - name: istio-egressgateway
      enabled: false
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true" # DNS 쿼리가 캡처돼 DNS 프록시로 리다이렉트된다
  values:
    pilot:
      env:
        PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION: true # 워크로드를 컨트롤 플레인에 자동 등록할 수 있다
        PILOT_ENABLE_WORKLOAD_ENTRY_HEALTHCHECKS: true # 가상머신 워크로드의 상태를 검사한다
    global:
      meshID: usmesh
      multiCluster:
        clusterName: west-cluster
      network: west-network

먼저 해주는 것은 DNS 프록시 설정이다.
매우 단순하게 ISTIO_META_DNS_CAPTURE: "true"만 달아주면 된다!
(참고로 vm에 대해서는 이게 기본 true로 세팅되기 때문에 여기에서 필수적으로 해야 하는 건 아니다.)
이제 각 워크로드가 배치될 때는 iptables에서 DNS 질의 트래픽 경로까지 조작될 것이다.

추가적으로 넣어주는 것은 컨트롤 플레인 세팅으로, 두 환경변수는 다음을 설정한다.^[7]
첫번째는 워크로드 그룹을 기반으로 엔트리가 자동으로 등록될 수 있도록 한다.
두번째는 워크로드 그룹에 명시된 헬스체크 설정을 가상 머신에 적용한다.

문서를 보다가 PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY: "true"라는 변수를 찾았다.
굳이 해보진 않았는데, 이 명령어를 적용하면 멀티 클러스터 등록 시에 서로의 워크로드 엔트리도 자동으로 가져온다고 한다.

아무튼 해당 설정들이 반영된 이스티오가 되도록 세팅한다.

istioctl install -f ch13/controlplane/cluster-in-west-network-with-vm-features.yaml --set values.global.proxy.privileged=true -y

정상적으로 세팅됐다면 istiod 파드 환경 변수에 다음의 값들이 확인된다.

이 설정이 완료된 이후에는 동서 게이트웨이를 세팅해주도록 한다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: istio-eastwestgateway
  namespace: istio-system
spec:
  profile: empty
  components:
    ingressGateways:
    - name: istio-eastwestgateway
      label:
        istio: eastwestgateway
        app: istio-eastwestgateway
        topology.istio.io/network: west-network
      enabled: true
      k8s:
        env:
        - name: ISTIO_META_ROUTER_MODE
          value: "sni-dnat"
        - name: ISTIO_META_REQUESTED_NETWORK_VIEW
          value: west-network
        service:
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: mtls
            port: 15443
            targetPort: 15443
          - name: tcp-istiod
            port: 15012
            targetPort: 15012
          - name: tcp-webhook
            port: 15017
            targetPort: 15017  
  values:
    global:
      meshID: usmesh
      multiCluster:
        clusterName: west-cluster
      network: west-network

이전 실습과 동일하게 동서 게이트웨이를 둔다.
이전에 무심코 열어두었던 15012, 15017 포트는 가상머신에서 istiod로 통신할 때 사용하게 될 포트이다.
istiod#네트워크 구성도(포트 정보) 참고.

istioctl install -f ch13/gateways/cluster-east-west-gw.yaml -y

이름이 다른 파일이기 때문에 install로 진행한다.
이전 세팅에 동서 게이트웨이가 추가되는 방식으로 세팅된다.

게이트웨이가 설치된 것이 확인된다.

참고로 말하자면 이러한 설치 방식은 사실 파일 자체의 이름으로부터도 영향을 받는다.^[8]
해당 양식의 메타데이터의 이름이 다르기도 했지만, 같은 이름이더라도 품고 있더라도 파일이 다르면 다르게 인식할 수 있다는 점에 주의힌다.
현재 방식에서는 애초에 다른 설정으로 개별적으로 세팅될 것을 기대하고 적용하는 것이라 오히려 좋다!

다음으로 해당 게이트웨이를 설정하는 게이트웨이 리소스를 세팅해야 한다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: cross-network-gateway
  namespace: istio-system
spec:
  selector:
    istio: eastwestgateway
  servers:
    - port:
        number: 15443
        name: tls
        protocol: TLS
      tls:
        mode: AUTO_PASSTHROUGH
      hosts:
        - "*.local"

해당 게이트웨이는 15443 포트를 통해 오토 패스스루를 수행한다.
이 경로로 가상머신의 트래픽이 들어오게 될 것이다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istiod-gateway
spec:
  selector:
    istio: eastwestgateway
  servers:
    - port:
        name: tls-istiod
        number: 15012
        protocol: tls
      tls:
        mode: PASSTHROUGH        
      hosts:
        - "*"
    - port:
        name: tls-istiodwebhook
        number: 15017
        protocol: tls
      tls:
        mode: PASSTHROUGH          
      hosts:
        - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istiod-vs
spec:
  hosts:
  - "*"
  gateways:
  - istiod-gateway
  tls:
  - match:
    - port: 15012
      sniHosts:
      - "*"
    route:
    - destination:
        host: istiod.istio-system.svc.cluster.local
        port:
          number: 15012
  - match:
    - port: 15017
      sniHosts:
      - "*"
    route:
    - destination:
        host: istiod.istio-system.svc.cluster.local
        port:
          number: 443

그리고 istiod로 들어오는 통신은 패스스루한다.
실험해보진 않았으나 여기도 오토 패스스루를 세팅할 수 있지 않을까 한다.

각종 리소스가 배치됐다.

k3s 세팅이기에 생기는 이슈가 하나 있는데, k3s 기본에서는 하나의 로드 밸런서만 배치될 수 있기 때문에 동서 게이트웨이만 로드밸런서가 되도록 세팅한다.

2. 워크로드 그룹 세팅

가상머신이 메시에 합류할 때, 워크로드로서의 설정과 클러스터 내 정보를 부여할 워크로드 그룹을 만들어본다.

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
  name: forum
  namespace: forum-services
spec:
  metadata:
    labels:
      app: forum
  template:
    serviceAccount: forum-sa
    network: vm-network
  probe:
    periodSeconds: 5
    initialDelaySeconds: 1
    httpGet:
      port: 8080
      path: /api/healthz

template 필드의 내용을 기반으로 istiod는 연결된 가상머신이 이 그룹에 속한다고 판단하게 될 것이다.
즉, vm-network의 forum-sa 신원을 가지고 연결된 가상머신이 이 리소스에 적용을 받는다.
그럼 해당 가상머신은 클러스터 내에서 app: forum 라벨을 가진 워크로드로 인식될 것이고 위 양식대로 헬스체크를 수행하게 된다.

kubectl create namespace forum-services
kubectl create serviceaccount forum-sa -n forum-services
kubectl apply -f ch13/workloadgroup.yaml

3. 가상머신용 설정 파일 생성

이제 가상머신이 이 워크로드그룹에 속하기 위해서는 설정될 파일에 관련한 정보들이 들어가야만 할 것이다.

istioctl x workload entry configure -h

istioctl에는 워크로드를 간편하게 등록할 수 있도록 도와주는 설정파일을 만드는 명령어를 제공한다!

기본적으로 워크로드그룹 양식을 인자로 받는다.
가상머신에서 통신하기 위한 경로, 가상머신이 사용해야 할 클러스터 id나 자동 등록 여부 등을 미리 여기에서 설정값으로 넣을 수 있다.

istioctl x workload entry configure -n forum-services --name forum \
  --clusterID "west-cluster" --autoregister \
  --capture-dns true \
  --ingressIP $APP_IP \
  -o /tmp/my-workload-files/

위에서 만든 리소스를 기반으로 설정 파일을 만들어본다.
(capture-dns가 가상머신 엔보이에 dns 프록시를 설정하는 기능인데 기본값이 활성화 상태라 명시하지 않아도 된다.)

보다시피 5가지의 파일이 생성되는 것을 확인할 수 있다.

• cluster.env
• hosts
• istio-token
• mesh.yaml
• root-cert.pem

cluster.env는 이스티오와 통신하는데 이용될 환경변수들이 담겨있다.
실제 파드에 프록시가 배치될 때도 이 변수들이 들어간다.

hosts 파일은 DNS에 사용되는 파일로, 컨트롤 플레인의 주소가 담긴다.
위에서 --ingressIP를 세팅했을 때의 값이 들어가며, 세팅하지 않으면 아무 값도 들어가지 않는다!
컨트롤 플레인과 연결이 되고 난 이후에는 각종 DNS 정보를 DNS 프록시를 이용하겠지만, 컨트롤 플레인과 최초 통신을 할 때 만큼은 이렇게 직접 통신할 수 있는 경로를 알려주어야만 한다.

istio-token은 서비스 어카운트 토큰이다.
가상머신은 이 토큰을 기반으로 통신을 하게 될 것이고, 이는 곧 메시 내 가상머신의 신원이 되어줄 것이다.
만료 시간이 부여돼있는데, 기본은 한 시간으로 잡혀있다.
달리 말하자면 별 옵션 없이 그냥 생성했다면 한 시간 안에 가상머신을 연결해야 하는 타임어택이 걸린 것이다!
(라고 해봐야 어려울 것 없으니 그냥 뚞딱하면 된다)

mesh.yaml 파일이 기본적인 설정 파일이다.
가상머신에 pilot-agent는 이 파일을 기반으로 구동하게 될 것이다.

root-cert.pem? 말해 뭐해

참고로 아래의 명령어를 이용해 워크로드 그룹을 만드는 것도 가능하다.

istioctl x workload group create -h

그러나 세팅할 수 있는 옵션에 헬스체크 관련 필드가 없어서 웬만해서는 그냥 직접 양식 파일을 만드는 것이 나아 보인다.

4. 가상머신 설정

이제 남은 것은 이 파일들을 가상머신에 넣고, pilot-agent를 구동시키는 것이다.
현재 각 인스턴스에 ssh 연결을 하고 있기에 scp를 통해 파일을 전송한다.

scp -i infra-terraform/key.pem -r /tmp/my-workload-files ubuntu@$FORUM:/tmp/

vm에서도 제대로 파일이 들어온 것이 확인된다.

설정 파일들은 전부 받았고, 이제 vm에서 실제로 실행될 파일을 설치해야 한다.

curl -LO https://storage.googleapis.com/istio-release/releases/1.25.1/deb/istio-sidecar.deb
dpkg -i istio-sidecar.deb

설치한 환경이 우분투이기에 데비안 패키지를 다운 받아 설치한다.

세팅을 하면 istio-start.sh라는 스크립트와 함께 실제로 동작하게 될 pilot-agent와 envoy가 설치된다.

해당 스크립트가 모든 초기화를 진행한다.
대충 보면 환경변수와 각종 설정 값들을 읽어오고, 이후에 pilot-agent를 이용해 iptables 조작과 envoy 실행을 수행한다.

해당 스크립트를 직접 실행할 필요는 없다.

여기에 systemd 서비스로 등록된 istio-sidecar를 이용해주면 된다.

cat /lib/systemd/system/istio.service

다만 스크립트가 구동될 때 사용할 설정 파일들의 위치를 세팅하고, 파일 소유권을 넘겨주는 작업은 필요하다.

먼저 사용자를 확인해보면 istio-proxy라는 놈이 추가된 것을 볼 수 있다.
이 사용자에게 파일 소유권을 넘기면 된다.

mkdir -p /etc/certs
mkdir -p /var/run/secrets/tokens

cp /tmp/my-workload-files/root-cert.pem /etc/certs/root-cert.pem
cp /tmp/my-workload-files/istio-token /var/run/secrets/tokens/istio-token
cp /tmp/my-workload-files/cluster.env /var/lib/istio/envoy/cluster.env
cp /tmp/my-workload-files/mesh.yaml /etc/istio/config/mesh
cat /tmp/my-workload-files/hosts >> /etc/hosts

chown -R istio-proxy /var/lib/istio /etc/certs /etc/istio/proxy /etc/istio/config /var/run/secrets /etc/certs/root-cert.pem

systemctl start istio
systemctl enable istio

기존에 들어간 세팅을 갈아엎기 싫어 값만 추가했다.
서비스가 구동되면 가상머신 측에서 할 세팅은 끝인 것이다!

실제로는 hosts 파일을 조금 다르게 세팅했다.
다른 네트워크를 가정했기에 위처럼 ec2의 공인 ip를 이용하거나, 최소한 앞단에 elb를 배치시켜서 해당 주소를 넣어주는 게 맞을 것이다.
그러나 돈 내기 싫어서 그냥 같은 vpc인 김에 사설 ip 값을 넣어주었다...
해당 통로를 통해서 이제 컨트롤 플레인과 가상머신이 지속 통신을 해야 하기에 인터넷 통해서 나가게 해서 괜히 비용을 물고 싶지 않았다.

보다시피 서비스가 구동되고 있다!
클러스터에서 파드들을 확인할 때 보였던 각종 설정 값들이 보인다.

확인

간단하게 설정들을 확인해보자.

가상 머신

iptables

먼저 세팅된 iptables를 확인해본다.

iptables -t nat -L -n -v
iptables -t raw -L -n -v

깜박하고 캡쳐하지 않았는데, 기본적으로는 원래 iptables에 아무런 값이 존재하지 않았다.
그러나 해당 서비스가 시작되자 iptables가 건드려진 것을 볼 수 있다.
이 테이블에 들어온 트래픽이 어떻게 envoy의 15006로 가는지, 나가는 트래픽은 어떻게 enovy의 15001으로 가는지, DNS는 어떻게 dns 프록시로 통하는지 전부 나와있다.

간략하게만 보자면,

• 인바운드 → PREROUTING → ISTIO_INBOUND → (예외 아니라면) → ISTIO_IN_REDIRECT → Envoy (15006)
• 아웃바운드 → OUTPUT → ISTIO_OUTPUT → (조건 검사) → ISTIO_REDIRECT → Envoy (15001)
• 로컬 DNS 요청 → ISTIO_OUTPUT_DNS → Envoy DNS (15053)

이에 대한 훨씬 자세한 내용은 8W - 엔보이와 iptables 뜯어먹기에 담겨있으니 이를 참고하자.

log

에이전트의 로그는 /var/log/istio에 남는다.

세팅에 실수가 있어서 에러가 발생했었다.
이때 당시 내가 한 실수는 다음과 같았다.

• 보안 그룹 열어두지도 않은 주제에 공인 ip로 통신하려함
• 밍기적대다가 토큰 기한 만료됨
  여기에서 밍기적대기도 했고 보안그룹 세팅을 제대로 안 해둬서 통신 간 조금의 에러가 있었다.

이밖에

ss를 통해 현재 연결된 소켓 정보를 확인해보면 제대로 세팅됐을 때 엔보이가 신나게 포트를 연결해두는 것을 확인할 수 있다.
맨 처음에 동서 게이트웨이 로드밸런서 세팅을 실패하는 바람에 잠시 트러블슈팅했다..

이스티오

istioctl을 통해 확인해보면 이제 상태 동기화를 하는 프록시로 forum이 추가된 것을 확인할 수 있다.

istiod의 로그를 보면 위와 같이 갑자기 wle라는 분류로 로그가 생성되는 게 보인다.
WorkLoadEntry가 탐지된 것이다!
연결된 vm을 검증하고 워크로드 그룹 매핑과 헬스체크를 수행한 이후에 XDS 설정을 푸시하는 것을 확인할 수 있다.

위 로그에 나오듯이, 워크로드 엔트리가 자동으로 등록 생성된 것을 확인할 수 있다.

yaml 파일로 꺼내보면, 보다시피 헬스체크에 실패했다!
사실 vm에 아직 아무런 워크로드를 올리지 않았기에 헬시고 자시고 한 게 당연한 것이다 ㅋㅋ

초기에 로그를 보도록 세팅해야 하는데 깜빡해서 중간부터 동서게이트웨이의 로그를 보는 중.
패스스루를 하기 때문에 게이트웨이 측에서는 정확한 신원을 파악하지 못하지만, 틀림없이 컨트롤 플레인과 통신하는 흐름이 확인된다.

가상머신 통신 확인

가상머신에 프록시가 성공적으로 세팅된 것은 확인했다.
그리고 가상머신을 istiod가 추적하고 있으니, 이제 실제로 서비스 메시 내부로서 통신이 가능한지 확인해본다.

가상머신에서 클러스터로

스터디 실습에서는 파이프로 패킷을 받아서 출력하던데, 왜인지는 모르겠지만 나는 잘 되지 않았다.

tcpdump -i any -w - udp port 53 | termshark

termshark는 기본적으로 원격 머신에서 루트 권한 없이 실행될 수 있다는 것을 가정하기 때문에, 실제로 패킷을 전달받았을 때부터 ui를 출력하도록 설계됐다.^[9]
그래서 패킷을 날리고 확인을 하려고 하면 ssh 세션이 끊긴 것마냥 입력을 받기만 하고 별다른 반응을 하지 않는 상황이 지속적으로 나왔다.

그런데 정말 모르겠지만, 패킷 필터링을 cli에서 먼저 하고 들어가려고만 하면 에러가 발생했다.
대신 아래 방법은 통했다.

termshark -i any

대신 그냥 들어가서 필터링 거는 건 가능해서 이렇게 패킷을 확인해본다.
원격의 패킷을 터미널로 시각화해서 뜯어볼 수 있다!

먼저 dns 질의 과정을 보자.

dig +short webapp.istioinaction

날린 요청이 자연스럽게 로컬의 15053 포트로 향하는 모습을 확인할 수 있다.

막상 보면 응답은 53포트로부터 돌아온다.
iptables를 통해 요청이 장난질 당해 엔보이를 거쳤다가 일반적으로 돌아온 것마냥 조작되고 있는 것이다.

다음은 간단하게 http 요청을 날린다.

curl -s webapp.istioinaction/api/catalog/items/1 | jq

http로 필터링을 걸어서 본 모습이다.
자연스레 요청은 로컬로 들어갔고, 응답은 10.43.99.102로부터 온 것으로 표시된다.

해당 ip는 클러스터 webapp의 ip로, 내 curl 요청은 자연스레 요청을 날린 곳으로부터 제대로 응답이 왔다고 확인하게 될 것이다.

반복 접근을 걸어두고 시각화 고트 키알리로도 확인해보자.
게이트웨이에서는 sni까지만 까보고 트래픽을 패스스루하기에 tcp 그래프로서만 표시되지만 http 트래픽으로는 forum으로부터 webapp, catalog를 거쳐서 트래픽이 이동하는 과정을 확인할 수 있다.

여기에 istiod로 가는 트래픽을 확인할 수 있는데, 이건 에이전트와 istiod가 통신하면서 일어나는 트래픽이다.
달리 말해 별다른 트래픽이 없더라도 istio system을 기준으로 그래프를 출력하면 항상 저 그래프는 확인할 수 있다.

아예 내 로컬에서도 요청을 걸어봤다.
내 요청은 기존에 뚫어둔 인그레스 게이트웨이를 통해 유입된다.

짤막 - termshark 사용법 끄적

vim에서 ctrl w를 두 번하면 분할 화면 이동이 가능한가..?
평소 쓸 때는 한번 누르고 hjkl로 이동하다보니 잘 몰랐는데, 아무튼 패킷 창 전환 시에는 두번 누르면 된다.
아하 tab으로도 가능하다.^[10]

이걸로 테이블 컬럼 필터링할 수 있다던데 암만 해도 없더라..

클러스터에서 가상머신으로

이번에는 거꾸로 가는 통신을 확인해서 최종적으로 메시가 잘 구성됐다는 것을 확실시하자.

apiVersion: v1
kind: Service
metadata:
  labels:
    app: forum
  name: forum
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: forum

클러스터 단에서 해야 하는 설정은 해당 가상머신에 띄워진(사실 아직 안 띄운..) 워크로드를 서비스로 연결하는 것이다.
이스티오 네이티브하게 만들자면 이스티오 서비스엔트리를 만들면 되는데, 그냥 이렇게 서비스로 만들더라도 차이는 없다.

서비스로 등록하기만 해도 당연히 모든 서비스들의 라우팅 설정에 포럼을 추적할 수 있게 된다.
모든 서비스가 되는 게 꼬우면 사이드카로 제한하세유

클러스터 정보도 확인할 수 있는데, 막상 엔드포인트를 보면 아무것도 없다.
가상 머신에 실제로 아무런 웹서버가 동작하지 않고 있으니 이는 당연하다.
헬스체크가 성공하지 않고 있기 때문에 컨트롤 플레인은 의도적으로 실제 엔드포인트를 등록시키지 않는다.

curl -s localhost:15000/config_dump | istioctl proxy-config listener --file -
curl -s localhost:15000/config_dump | istioctl proxy-config route --file -
curl -s localhost:15000/config_dump | istioctl proxy-config clusters --file -
curl -s localhost:15000/config_dump | istioctl proxy-config endpoint --file -
curl -s localhost:15000/config_dump | istioctl proxy-config secret --file -

이제 정말로 가상머신에 생각했던 워크로드를 배포하고 트래픽을 확인해보자.

wget -O forum https://git.io/J3QrT
chmod +x forum
./forum

실습에서는 바로 실행을 때릴 수 있게 바이너리를 다운 받을 수 있도록 배려를 해주고 있어 간편하게 포럼 서비스를 만들 수 있다.

다시 istioctl pc로 확인해보면 이제는 엔드포인트가 보이는 것이 확인된다!

k -n forum-services get we forum-192.168.10.200-vm-network -oyaml

헬스체크를 성공하기에, 워크로드 엔트리 리소스에도 이 정보가 그대로 반영된다.

그럼 이제 통신을 보낼 수 있는가?

while true; do curl -s -H "Host: webapp.istioinaction.io" http://$APP_IP:30000/api/users ; echo; date; sleep 1; done

내 로컬에서 웹앱을 거쳐 webapp을 거쳐서 요청을 보내본다.

키알리로도 확실하게 포럼 서비스에 접근이 되는 것이 확인된다!
이제 정말 가상머신을 메시 내부로 들였다고 이야기할 수 있겠다!!

인증 정책 적용

마지막으로 해볼 것은 간단하게 인증된 사용자만 가상머신에 접근 가능하게 하는 것이다.

curl -is $FORUM:8080/api/users | grep HTTP

현재 포럼 ec2는 내 로컬에서의 트래픽을 전부 받을 수 있도록 보안그룹이 열려있고, 메시 차원에서 어떠한 보안 정책도 걸어두지 않았다.
그래서 내 로컬에서도 문제 없이 통신이 가능하다.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

이 통신을 막는 방법은 간단하다.
메시 내에서 mtls를 강제하는 순간부터는 메시 내에서 신뢰된 도메인 기반의 신원을 가진 트래픽만 통신할 수 있게 바뀐다.

kubectl apply -f ch13/strict-peer-auth.yaml

이제부터는 내 로컬로부터의 통신이 불가능해진다..
위에서 잠시 봤지만 가상머신의 iptables에서는 ssh를 막지 않기 때문에 현재 세션은 여전히 문제가 없다.
그렇지만 이외의 트래픽은 보다시피 mtls를 강제받게 된다.

물론 webapp은 인그레스 게이트웨이로 뚫려있는 상태이고 이에 대해 모드를 설정하지는 않았기에 여전히 문제없이 통신이 가능하다.
결론적으로, 이제 가상머신이 완벽하게 데이터플레인의 일원으로 트래픽 관리를 받는다는 것이 확인됐다.

DNS 프록시 동작

iptables-save | grep 'to-ports 15053'

보다시피 127.0.0.53의 53포트로 가는 모든 요청은 15053으로 리다이렉트된다.
참고로 127.0.0.53은 system-resolved라는 우분투 os의 리졸버의 주소이다.

ss -tunlp | grep 127.0.0.53

system-resolved는 실제 외부 네임서버로 질의를 날리기 이전, 캐싱이나 내부 호스트 네임 해석을 제공하는 리졸버 데몬이다.
기본적인 모든 dns 요청은 이놈을 향하는데 iptables로 이걸 프록시로 돌려버린 것이다!

그래서 DNS 프록시로서 에이전트는 어떻게 동작하는가?

외부 도메인에 대해

일단 첫번째로 클러스터의 도메인이 아닌 경우에 대해서는 원래대로 로컬 리졸버에게 질의를 날린다.
간단하게 외부 주소 질의를 날리고 termshark로 확인해보자.

dig +short naver.com

통신의 흐름은 총 4번 추적된다.
먼저 내 요청이 에이전트에 전달됐다.

이후 패킷 도둑 에이전트가 자신도 모른다 싶으니 나 몰라라 로컬 리졸버에게 질의를 날려버린다.
이후에는 해당 응답이 돌아오고, 에이전트가 자신이 리졸버인 척 처음 요청에 대한 응답을 반환하는 식으로 구성된다.

그런데 에이전트 스스로의 도메인 질의는 왜 자신에게 돌아가지 않는가?
iptables를 보면 이 답을 확실하게 알 수 있다.

iptables -t nat -L -n -v

에이전트의 UID, GID가 998인 것은 아까 위에서 확인했을 것이다.
그냥 iptables 상에서 본격적으로 조작이 일어나는 체인은 맨 아래 ISTIO_OUTPUT_DNS, ISTIO_REDIRECT인데 해당 체인에 들어가기 전에 먼저 GID가 998이면 리턴을 때려버려서 정상적으로 패킷이 처리되는 것이다.

클러스터 도메인에 대해

클러스터 도메인 질의는 위에서 찍은 사진으로 대체한다.

dig +short webapp.istioinaction

날린 요청이 자연스럽게 로컬의 15053 포트로 향하는 모습을 확인할 수 있다.

여기에서는 패킷의 흐름은 두 번에서 끝난다.
즉 에이전트가 해당 도메인에 대해 추가 질의를 하지 않고 그대로 응답을 해버린 것이다.

위 도식에서 나오듯이 에이전트는 istiod로부터 NDS api를 통해 도메인 정보를 전부 가지고 온다.
istiod에서는 이를 디버깅할 수 있도록 엔드포인트를 노출하고 있다.

kubectl -n istio-system exec deploy/istiod -- curl -Ls "localhost:8080/debug/ndsz?proxyID=forum-vm.forum-services" | jq

보다시피 proxyID 별로 적용되는 설정을 조회할 수 있다.

그러면 이렇게 네임테이블이 출력되는데, 이게 에이전트가 받게되는 테이블인 것이다!
여기에는 전부 FQDN 밖에 없는데, 이 정보를 받고 에이전트는 자체적으로 해당 값들을 잘개 쪼개 도메인으로 엔보이에 전달한다.
그래서 엔보이 라우트 쪽 설정을 보면 여러 도메인이 들어있는 것을 확인할 수 있는 것이다.

NDS가 전달되고 있다는 것은 istiod 로그로도 확인할 수 있다.

k -n istio-system logs istiod-848dbb56f6-s86t6 | grep NDS

보다시피 포럼 측은 지속적으로 NDS를 통해 istiod로부터 설정을 받고 있는 것을 확인할 수 있다.

가상머신 프록시 커스텀

이건 실습은 하지 않고 정보만 남겨둔다.
초기 스크립트를 보면 여러 설정 정보들이 들어간 환경 변수 파일이 두 가지 있는 것을 알 수 있다.
하나는 처음 클러스터 측에서 가져왔던 cluster.env이다.
다른 하나는 프록시 바이너리를 설치할 때 딸려온 sidecar.env이다.

cat /var/lib/istio/envoy/sidecar.env

여기에는 죄다 주석밖에 없다.
XDS를 통해 전달되는 설정 말고 환경에 대해 추가 커스텀이 필요하다던가 할 때는 이걸 수정하고 서비스를 재시작시켜주면 된다.

예를 들면 여기에 CA 서버 경로 같은 것도 설정할 수 있다.

이밖에도 로그 레벨 설정 같은 엔보이에 있어 꽤나 코어한 커스텀도 이걸 수정해서 반영하면 된다.
위에서 잠시 봤듯 istioctl proxy config을 가상머신에 세팅할 수 없기 때문에, 아예 해당 파일을 외부에서 수정하고 변경에 맞춰 서비스를 재시작시켜주는 프로세스를 세우면 운영에 유용할 것이다.

정리

kubectl create serviceaccount forum-sa -n forum-services
kubectl apply -f ch13/workloadgroup.yaml
istioctl x workload entry configure -n forum-services --name forum \
  --clusterID "west-cluster" --autoregister \
  --capture-dns true \
  --ingressIP 192.168.10.10 \
  -o /tmp/my-workload-files/

scp -i infra-terraform/key.pem -r /tmp/my-workload-files ubuntu@$FORUM:/tmp/
# If you reach in this comments, it's time to set the files in the VM instance!
curl -LO https://storage.googleapis.com/istio-release/releases/1.25.1/deb/istio-sidecar.deb
dpkg -i istio-sidecar.deb

mkdir -p /etc/certs
mkdir -p /var/run/secrets/tokens

cp /tmp/my-workload-files/root-cert.pem /etc/certs/root-cert.pem
cp /tmp/my-workload-files/istio-token /var/run/secrets/tokens/istio-token
cp /tmp/my-workload-files/cluster.env /var/lib/istio/envoy/cluster.env
cp /tmp/my-workload-files/mesh.yaml /etc/istio/config/mesh
cat /tmp/my-workload-files/hosts >> /etc/hosts

chown -R istio-proxy /var/lib/istio /etc/certs /etc/istio/proxy /etc/istio/config /var/run/secrets /etc/certs/root-cert.pem

systemctl start istio
systemctl enable istio

쿠버네티스 클러스터에 속하지 않은 환경을 이스티오 메시에 통합하는 것이 꽤나 낯설게 들렸지만 막상 보면 그렇게 어렵지 않았다.
이미 많은 부분을 상당히 자동화해주고 있어 실상 설정을 위해 짠 스크립트만 치면 20줄 되려나.

이스티오 측에서는 가상머신 워크로드를 워크로드 엔트리로서 관리하고 있기 때문에 막상 보면 환경을 정리하는 것도 굉장히 간단하다.
그냥 해당 인스턴스를 종료시키면 에이전트와 엔보이 프로세스가 사라지는데, istiod가 이를 감지하고 워크로드 엔트리를 알아서 없애버리기 때문이다.

몇 가지 자동화를 위한 세팅이 들어가기는 하지만 어차피 요즘이야 워낙 IaC 툴도 많고 여차하면 쉘 스크립트로 뚝딱 해버리면 되다보니 더더욱 어렵지 않을 것이다.

참고로 이번에 인스턴스 내부에 적용된 설정들을 추적하는 내용이 많았는데, 더 자세한 내용을 다음 글에 담았다.

번외 - 가시다님의 실패 경험

이번 내용을 보면서 이렇게 하면 어떨까 저렇게 하면 어떨까 생각이 많이 들었는데, 결론적으로는 시도하지 않았다.
가시다님의 실패 경험 정리 부분을 보았기 때문..
저번 주 내용 정리도 다 끝나지 않은 시점에 이번 주까지 너무 일을 크게 벌릴 수는 없겠다 싶어서 스터디 내용을 충실히 따라갔다..
대신 어떤 부분들이 이슈였는지, 내가 추후에 다시 이 부분에 도전할 일이 있다면 어떻게 대처해야 할지 생각해보기 위해 정리해둔다.

첫번째로 다른 VPC에서 환경을 구성할 때 엔보이가 내부 IP로 동서 게이트웨이에 접근했다고 한다.
엔보이는 에이전트가 만들어둔 통로를 이용해 통신하므로, 에이전트와 istiod가 통신을 주고받는 과정에서 일이 발생한 게 아닐까 하는 생각이 든다.
istiod가 통신하면서 자신의 정보를 잘못 노출한 게 아닐까 하는 생각이 든다.
만약 그게 정말 이슈라면, 이는 동서 게이트웨이가 아니라 클러스터 외부의 로드밸런서를 배치할 때도 발생할 수 있는 문제이다.

이전 글, 다음 글

• 6W - 이스티오 컨트롤 플레인 성능 최적화: 21
• 8W - 엔보이와 iptables 뜯어먹기: 23

다른 글 보기

관련 문서

지식 문서, EXPLAIN

기타 문서

참고